In multi-tenant database systems, customer organizations (also referred to as “tenants”) may share database resources in one logical database. The databases themselves are typically shared, and each tenant is typically associated with an organization identifier (org ID) column or field that may be used to identify rows or records belonging to each tenant. Each tenant may provide their own custom data, which may include defining custom objects and custom fields, as well as designating one or more custom fields to act as custom index fields. The multi-tenant database system may store custom index data in a canonical data format in a custom index table with linkages to corresponding org IDs. The custom indexes may be canonicalized to keep the custom indexes in a standard or normalized format, for example, where custom indexed data values may have logically identical values but may not have an identical binary representation. When a user issues a database query with a filter, the filter may be converted to the canonical data format used by the custom index table prior to being issued against the custom index table.
In many scenarios, it may be desirable to update the canonical data format used for the custom index data in the custom index table. Such scenarios may include fixing bugs that cause issues when canonicalizing custom index data, which may result in data being hidden or un-retrievable from a tenant space; upgrading to a new unicode version; and/or adopting a more efficient or compact canonical data format that may reduce computational resources needed to canonicalize index data and/or allows for queries to be searched faster or more efficiently. Converting index data and/or custom index data into a new format may be a computationally intensive process. Depending on the size of the database system, such a conversion process may take many hours to several weeks to complete. In addition, since most conversion processes are very computationally intensive, such processes may result in slower database response times, etc. which may be caused by heavy database utilization during the index data format change process. In some cases, the conversion processes may require a database system to be shut down or taken offline in order to complete the index conversion process.